UPDATE: Microsoft has patched the bug in october 2020 patch and the following CVE was assigned CVE-2020-16908
Summary:
Let's check out what did Microsoft about this vulnerability
An elevation of privilege vulnerability exists in Windows Setup in the way it handles permissions.
A locally authenticated attacker could run arbitrary code with elevated system privileges. After successfully exploiting the vulnerability, an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
The security update addresses the vulnerability by ensuring the Windows Setup properly handles permissions.
I was the founder of the vulnerability.
The vulnerability exist when the windows setup doesn't properly enforce permission on C:\$WINDOWS.~BT folder creation allowing a local user to execute arbitrary code with system privileges.
Let's take a look on windowsupdatebox.exe before the security patch
As you can see there's a CreateDirectory (as I highlighted in red) which is written in the following form
CreateDirectoryW(FileName, 0i64)
0i64 -> NULL
FileName -> C:\$WINDOWS.~BT
Actually creating a directory with null security descriptor in c:\ allow authenticated users to have read&write&delete access on the directory because of the default inherit permission from c:\
However after few code (the blue highlighted ones) there's a call of SetSecurityInfo which change the security descriptor of the directory, it's clearly a race condition, a user will attempt to set a reparse point to an arbitrary location after the CreateDirectoryW and before the CreateFile call. That's a short description for CVE-2020-1571.
Let's try to do some damage, let's take a look at the patched function
Seems look like there's no SetSecurityInfo call anymore but instead they pass the security descriptor to the function directly which prevent abuse or a possible race condition.
Interesting but there's still something we can look for, let's drive deeply in the code, let's find operation before this function was called maybe we can find something we can abuse.
The caller actually do some initialization before trying to create this directory,
I was looking for something until I saw this and I can smell the vulnerability here, and after taking a look I found something. It seem look like that the clean-up process attempt to delete C:\$WINDOWS.~BT before attempting to create the directory again without properly checking for reparse point, it's probably an abuse able point for arbitrary file deletion. Let's look what procmon gonna say
And as it should be there's no SetSecurityFile, but what if the directory already exist ? as we seen in the code it must deleted
And as you can see here WindowsUpdateBox is trying to delete the directory with the entire subcontent, it seems look like there's a check for reparse point but it's not really enough to prevent abuse, if we put an oplock and then switched a reparse point we will have a TOCTOU.
The technique used here is the same one used in the windows defender zero day bug which I disclosed a month ago https://0x00sec.org/t/windows-defender-av-zero-day-vulnerability/22258
It took from me a day to find & write poc & write this write-up.
NOTE: The bug is only exploitable on windows 10, on any version of lower than 2004.
Steps To Reproduce:
- Run the poc
- Go to settings->updates->Feature update to windows 10, version X
- A SYSTEM shell should be spawned
PoC Video:
